As the popularity of the Internet and E-commerce continues to grow, the issue of security is a primary concern. In order for online transactions to continue to be a viable alternative to traditional transactions, mechanisms to secure connections between parties is critical. In a public key infrastructure, each party needs a key pair made up of one key that is made public (the public key) and another key that is kept private (the private key). The public key is placed in a digital certificate and signed using an algorithm such as the well-documented digital signature algorithm (DSA) to verify that the owner of the public key is indeed who they claim to be. While some applications allow the owner to create the key pair and generate the digital certificate themselves, in applications wherein security is of particular concern, a third party called a certificate authority (CA) is often used to verify the identity of the owner of a public key pair.
In many cases, the CA will use a registration authority (RA) to determine whether the digital certificate should be issued to the owner of the key pair. The RA will often keep a backup copy of the owner's private key, which is generally referred to as key escrow. Clearly, the escrowed copy of the private key must be securely stored and protected to avoid unintentional disclosure. There is therefore a need to securely escrow a private key such that it is very difficult for an unauthorized party to gain access to it.
While a number of approaches to key escrow have been developed, certain difficulties remain. FIGS. 1 and 12-14 demonstrate a conventional approach to key escrow, and highlight these difficulties. Specifically, FIG. 1 shows a public key infrastructure wherein an end user 130 is provided a key pair 132 by a primary site 140 over a secure connection via network 160. It can be seen that a key management server (KMS) 180 stores a key recovery record (KRR, or encrypted private key) 20, which is an encrypted version of the private key in key pair 132, and recovery data 22 in a primary database 24 located at the primary site 140. A session key is used to secure the encrypted private key 20.
FIG. 14 illustrates a conventional approach to structuring the recovery data 22 (FIG. 1). Generally, it can be seen that the session key and a password are encrypted with the public keys of three entities: Key Recovery Coordinator (KRC), Key Recovery Officer (KRO), and Key Recovery Agent (KRA). A password is provided by an administrator at the primary site 140 (FIG. 1), and the session key is generated by the key management server 180 (FIG. 1). The recovery data 22 is sometimes referred to as the Key Recovery Block (KRB). Returning now to FIG. 1, it will be appreciated that to recover a private key, authorized key recovery personnel such as the administrator discussed above, sends the recovery data 22 to a key recovery server located at a secondary site 26 along with a candidate password provided by the administrator. The candidate password must match the password contained in the recovery data 22 before the secondary site 26 will provide the recovery requesting administrator with the session key.
Thus, FIG. 12 illustrates that a private key is encrypted with a session key at processing block 28, and the recovery data 22 and encrypted private key 20 are stored at the primary site 26 (FIG. 1) in processing block 30. FIG. 13 illustrates that in order to recover the private key, the recovery data 22 and the encrypted private key 20 are retrieved from the primary site memory at block 32, and the recovery data 22 and candidate password are sent to the secondary site 26 at block 34. The key recovery server (KRS) 36 decrypts the recovery data 22 using the KRC, KRO and KRA public keys and determines whether the candidate password 38 supplied by the administrator matches the password contained within the decrypted recovery data 22. If so, the session key 40 is sent from secondary site 26 to primary site 140. Once received at block 36, the encrypted private key is decrypted at block 42 based on the session key 40. The result is private key 44, which can be re-sent to the end user 130 (FIG. 1).
While the above-described approach has been satisfactory in certain circumstances, significant room for improvement remains. For example, by storing both the encrypted private key 20 and the recovery data 22 at the primary site 140, a password mechanism is required in order to recover the private key. Changes in personnel and the continuing concern for security, however, mean that password changes are often necessary. For example, if a particular administrator supplies the password that is contained in the recovery data for a private key, and subsequently discontinues employment with the primary site 140, the administrator's password must be changed. When this occurs, the entire KRB 22 must be regenerated with the new password. Selectively regenerating KRBs based upon personnel changes is administratively complex and inconvenient. There is therefore a need to restrict access to private keys in a public key infrastructure in which passwords are not required.
Another difficulty relates to the use of encryption to secure the recovery data 22. Specifically, the KRC, KRO and KRA key pairs require digital certificates, which often are obtained by the secondary site 26 from one or more external sources. For example, in one commercially available system, the digital certificates must be obtained from the provider of the KRO/KRC/KRA encryption/decryption code. When the secondary site 26 receives the certificates, they are embedded in a configuration file, which is shipped to the KMS 180 (FIG. 1) and installed along with a tool kit capable of performing the encryption. When the certificates expire, however, the tool kit is no longer able to perform the encryption to generate the recovery data 22. Obtaining new, current certificates in a timely fashion can be complex and inconvenient. As a result, undesirable measures such as clock resetting are sometimes resorted to until the new configuration file can be obtained. The consequences are particularly acute when the secondary site 26 must obtain the certificates from an external source as discussed above. There is therefore a need to provide an approach to generating recovery data that does not require the password-protected encryption of a session key with certificates while maintaining an adequate level of security.